This invention relates to computer programs, and more particularly to addressing schemes for sending messages to peripherals connected to clustered computers.
In a client/server architecture, server computers may be grouped together into a cluster. A cluster could have one default server and at least one backup server. If the default server fails, all incoming messages are routed to the backup server so that it becomes the default server. In this configuration increased fault tolerance is provided. Switching between servers may be achieved through a shared common access address for all servers in the cluster, such as, a common Internet Protocol (IP) address. One software product for providing such a common address for a cluster and the capability of switching between servers has been designed by the Microsoft Corporation, of Redmond, Wash., called the Microsoft Cluster Server.
Often times each server in a cluster is connected to the same peripheral device. This peripheral may contain data storage for client applications. All clustered servers are capable of accessing this data and providing it to client applications, but only one server (the aforementioned default server) will access the data at any one time. The clustered servers all use the same xe2x80x9cnamexe2x80x9d or xe2x80x9chandlexe2x80x9d to refer to a peripheral device, such as, a data storage area (this name is typically provided by the user when creating the data storage). Clustering technology allows the client application to be unaware of which server is handling the request for accessing the data storage area, because all servers are capable of responding to the common IP address of the cluster, and all servers use the same xe2x80x9cnamexe2x80x9d or xe2x80x9chandlexe2x80x9d to refer to the data storage area. Therefore, when the default server fails, the backup server transparently provides access to the data storage area, because the xe2x80x9cnamexe2x80x9d or xe2x80x9chandlexe2x80x9d will be the same.
However, when the client application is actually managing the peripheral device (as opposed to accessing the data on it), the xe2x80x9cnamexe2x80x9d or xe2x80x9clocal pathxe2x80x9d of the device may not be the same between servers in the cluster. For example, if the peripheral is a storage processor, the device name on one server may be a concatenation of the host bus adapter slot number, the disk array storage processor slot id, and a logical unit number (lun) on the disk array. If another server in the cluster uses a different host bus adapter slot number, the concatenated device name or local path will be different. This will result in a loss of the ability to transparently manage the peripheral in a cluster, which is unacceptable and contrary to the services provided by clustering software. In the text that follows, the term local path and concatenated device name shall be synonymous.
Client applications that manage peripherals commonly communicate with the peripheral via xe2x80x9cagentxe2x80x9d software running on the server connected to the peripheral. This agent uses commonly known network transport mechanism (i.e. sockets over TCP/IP) to send and receive data to and from client applications. Should the client application wish to send a message to a peripheral device of a server, the client application will pass the message, along with the concatenated device name, to the agent. The agent will then simply pass the message to the peripheral using an established method provided by the server""s operating system (i.e. a SCSI pass-through IOCTL interface). FIG. 1 shows a block diagram of a client sending a message to a server cluster. The designation xe2x80x9cABCxe2x80x9d represents the complete local path. In this example the final destination is a storage processor that is attached to the server. Here the letter xe2x80x9cAxe2x80x9d represents the host bus adapter, the letter xe2x80x9cBxe2x80x9d represents the SCSI address of the storage processor, and the letter xe2x80x9cCxe2x80x9d represents the LUN unit on the storage processor that is to be communicated with.
Providing the full local path is an adequate addressing solution, as long as, the default server does not fail. When the default server fails and the message is rerouted to the backup server, the local path may no longer be valid. FIG. 2 shows a block diagram of this situation. Server xe2x80x9cXxe2x80x9d fails and the message is routed to server xe2x80x9cYxe2x80x9d. The message/request is attempting to reach a logical group of disks xe2x80x9cCxe2x80x9d, however the local path is not xe2x80x9cABCxe2x80x9d but is now xe2x80x9cDECxe2x80x9d. Thus, in this prior art addressing scheme, the message fails to reach the destination.
In accordance with one aspect of the invention, a method of forwarding a message received by a server to a coupled hardware device is provided. The method may also be accomplished in a server cluster where the server cluster is comprised of a default server and a coupled backup server.
A look-up table is created in the server for fall hardware devices coupled to the server by a server agent. The look-up table relates a unique identifier of a hardware device to a local path (i.e. xe2x80x9cABCxe2x80x9d). The lookup table is stored in memory accessible by the server agent.
The server agent sends all of the hardware identifiers to the client. Typically, this occurs as the result of a client application requesting this information. The client can then send a message for a hardware device connected to the server. The message is attached to a unique identifier which contains the hardware identifier. The server agent then extracts the identifier from the message, because the server and the client are using an agreed-upon structure to send messages back and forth to each other. The server then retrieves the look-up table and locates the path in the look-up table for the coupled hardware device based on the hardware identifier parsed from the unique identifier. The message is then forwarded through the path to the hardware device.
If the method is implemented in a server cluster environment, each server may initially identify if any hardware devices are attached to the server and access a hardware identifier for each hardware device that is found attached to the server. The hardware identifier can be accessed using standard protocols such as SCSI mode sense, or the protocols suggested by the attached peripheral. From the hardware identifiers, each server creates a look-up table. The lookup table is an association between the hardware identifier and a path where the path comprises a local access channel from the input of the server to the hardware device. Port numbers of the hardware device may be included within the unique identifier.
Preferred embodiments of the invention are implemented as a computer program product having a computer usable medium with computer readable program code thereon. The computer readable code may be read and utilized by the computer system in accordance with conventional processes.